home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / iso9660 / mail / pine / c_client.arc / text0044.txt < prev    next >
Encoding:
Text File  |  1993-07-31  |  3.2 KB  |  76 lines
  1. I'd welcome the addition of these to IMAP. I've got a few questions:
  2.  
  3. Would the functions just return plain unparsed strings? If so, then the
  4. Resent-xxxx: cases would require the client to do address parsing. This
  5. isn't a huge problem since the routines are there in the client anyway.
  6.  
  7. It sounds like you have a choice of requesting the header lines that you
  8. want, one at a time, or parsing a big string that comes back. The problem
  9. with requesting the lines one at a time would be an RTT for each one,
  10. right? 
  11.  
  12. I'm also having trouble coming up with a use for the LINES.NOT function.
  13. Did you have something in mind? That's not to say it should be take out. 
  14.  
  15. I'm interested in the References: field for threading news groups and other
  16. mail folders. I think you need it because the full tree of In-Reply-To:'s
  17. might not be in the mailbox being threaded.
  18.  
  19. Laurence Lundblade
  20.    lgl@csgrad.cs.vt.edu or lgl@cac.washington.edu (forwarded to same place)
  21.       Blacksburg, Virginia or Seattle, Washington
  22.  
  23.  
  24. On Sun, 18 Apr 1993, Mark Crispin wrote:
  25. > 
  26. > I, perhaps more than anyone else, want to put a lid on further IMAP additions
  27. > in the name of stability and getting a Proposed Standard out of this.
  28. > However, something has come out that has survived even my harsh filters, and
  29. > I'm throwing it out to the list to be blessed (or damned, as the case may be).
  30. > 
  31. > The proposed change is a new form of FETCH which allows the selecting fetching
  32. > of message headers.  The problem to be solved is that RFC-822 certain header
  33. > lines are not represented in the IMAP envelope structure, nor is there any
  34. > reasonable way to extend the envelope structure to accomodate them.  It is
  35. > considered mandatory that any extension be upwards/downwards compatible and
  36. > not require revisiting the next time we need to be able to snarf another
  37. > header.
  38. > 
  39. > The most obvious example is the ReSent-Date/ReSent-From/ReSent-To header
  40. > lines.  There is an additional problem with these particular header lines in
  41. > that they can not be arbitrarily reordered and retain the same meaning.
  42. > 
  43. > Other headers, such as Newsgroups:, are also perceived as interesting.
  44. > 
  45. > The proposed two new functions are a ``fetch all header lines of this message
  46. > whose field names match any in this list'' and ``fetch all header lines of
  47. > this message whose names do not match any in this list''.  They take an
  48. > argument which consists of a list of the field names.  The result of these
  49. > functions is a text string similar to that from RFC822.HEADER.  All header
  50. > lines are returned in the original order of the message (note this is a
  51. > requirement for useful ReSent information).
  52. > 
  53. > For example (note that line breaks are here only for clarity):
  54. > 
  55. > A001 FETCH 23:30 (ENVELOPE RFC822.HEADER.LINES ("Resent-Date" "Resent-From"
  56. >          "Resent-To")
  57. > 
  58. > would fetch the envelopes and remail information for messages 23 to 30.
  59. > 
  60. > A001 FETCH 23 RFC822.HEADER.LINES.NOT ("Return-Path" "Received")
  61. > 
  62. > would fetch the header of message 23 without the ``Return-Path'' or
  63. > ``Received'' header lines.
  64. > 
  65. > This would become a fundamental API call in c-client, and c-client would
  66. > simulate its results if it finds itself talking to an IMAP server that does
  67. > not support it.
  68. > 
  69. > Comments please.
  70. > 
  71.  
  72.  
  73.  
  74.  
  75.  
  76.